Database systems are becoming increasingly specialized for specific workloads. In particular, an in-memory database management system (DBMS) becomes more appropriate for OLTP as the vast increases in Internet and telecommunication-based applications require shorter response times and higher throughput in transaction processing (i.e., features that cannot be provided by disk-based systems due to slow disk access response times).
Recent work in the OLTP database area has demonstrated performance improvements of close to two orders of magnitude by running DBMS in main memory for OLTP when compared to traditional disk-based DBMS. There are, however, significant limitations that have prevented widespread adoption of such in-memory DBMS. Typically, the property of “durability” in the ACID model (atomicity, consistency, isolation, durability) for database management is satisfied by “synchronously” logging update and insertion transactions to disk, ensuring that the transactions are committed and written to persistent storage (e.g., disk) prior to notifying the requestor of such transactions of their successful completion (i.e., in contrast to “asynchronously” logging transactions to disk after notifying the requestor of successful completion, which is less likely to satisfy the durability concerns). However, because disk accesses are slow in comparison to memory accesses, committing and writing update and insertion transactions to disk in such a synchronous manner prior to notifying the requestor of successful completion can significantly slow down the response times of an in-memory DBMS for OLTP, which caches data in memory precisely to avoid such slower accesses to disk.
To address performance bottlenecks caused by such slow disk access required for durability, certain in-memory database systems have multi-threaded capabilities so that transactions can be serviced in parallel (e.g., launching a new thread for each new database transaction). In such systems, synchronously logging a transaction to disk for one transaction in one thread, while slowing down the performance for the transaction itself, does not impede completion of a different transaction (i.e., running in another thread) that is accessing different data in the database (i.e., does not conflict with other transactions). However, such multi-threaded systems require complicated data access (e.g., locking or latching mechanisms to avoid collisions between threads), buffer management (e.g., for allocating memory for the parallel threads) and logging (e.g., for more efficiently writing data for multiple parallel transactions to disk) capabilities that often cause significant performance penalties due to the necessary computing overhead to implement such capabilities.
In contrast, single threaded in-memory database systems service transactions serially in a single thread rather than in parallel through multiple threads. As such, single-threaded in-memory database systems do not require the aforementioned mechanisms to manage issues arising from parallelism and therefore do not suffer from any computing overhead required to implement such mechanisms. However, single-threaded in-memory database systems cannot synchronously log a transaction to disk without affecting the response times of all subsequent transactions received by system since such transactions are serviced sequentially. Current single-threaded in-memory database system instead rely on standby replicas to satisfy durability requirements. However, many database administrators do not feel that standby replicas (which essentially provide another in-memory backup of the transactions) sufficiently address durability concerns.
Furthermore, the possible size of system memory for a computer system remains a limiting factor in the performance of an in-memory database system running on the computer system. Traditional virtual memory management techniques of overcommitting available system memory by providing virtual memory address spaces that are larger than the available system memory itself and then swapping pages of memory to disk when the computer system experiences memory pressure can further degrade performance of an in-memory database system on a single computer system due to the slow accesses to disk. While in-memory database systems can be implemented for large scale data intensive applications using a cluster of computer systems that can, in the aggregate, provide significantly more system memory than a single computer system, such clustered systems require complex techniques to properly balance and partition data among the clustered systems and minimize network bandwidth and latency issues.